refactor(guest-agent): restrict GetQuote to Intel TDX - #1107

Restricting `GetQuote` to Intel TDX closes the backend path
`Worker.GetAttestationForAppKey` used, so on SEV-SNP and Nitro that
method can no longer answer -- its response type is `GetQuoteResponse`,
and there is no quote to put in it. That leaves the external listener
with no way to attest an app key at all. `Attest` is no substitute: it
lives on the internal unix socket, and an external caller could not use
it even if it did not, because `Attest` takes the report data from the
caller and the caller does not know the app key's public key until the
agent derives it. Deriving the key and building the report data is the
whole reason this method exists.

`AttestAppKey` is that method with a response that can carry every
platform's evidence: same request, `AttestResponse` instead of
`GetQuoteResponse`. Nothing is lost against the old shape -- the
versioned attestation carries the report data and vm_config that
`GetQuoteResponse` exposed as separate fields, and the quote and event
log inside it.

The old method is removed rather than kept alongside. It has shipped
since v0.5.7, so this is a breaking change, but no SDK exposes it, the
tree has no callers outside these tests, and on every platform but TDX
it already returned an empty quote plus the field-5 attestation that
never shipped. Keeping a TDX-only alias of a method that now works
everywhere would cost more than it buys.

`GetAttestationForAppKeyRequest` is renamed to `AttestAppKeyRequest`;
message names do not appear on the wire.

The report-data derivation moves to `app_key_report_data`, which also
gained a bounds check: a public key encoding longer than the 64 bytes of
report data used to panic on the slice copy.

…f production

`with_report_data` has one non-test caller in the tree -- the simulator --
and it is a `pub fn` on a crate that kms, gateway, verifier, guest-agent
and dstack-util all depend on. What it does there is rewrite bytes
568..632 of a signed TDX quote, which leaves the signature covering the
bytes that used to be there. The output is evidence-shaped and cannot
pass verification. That is exactly right for a simulator whose callers
skip verification, and wrong for every other consumer of this crate.

That mismatch is why the missing `GcpTdx` arm went unnoticed for so
long: nothing about the function's placement said "only one caller, and
it is a simulator".

Put it behind a `simulator` feature, `#[cfg(any(test, feature =
"simulator"))]`, passed through `ra-tls` to the one crate that needs it.
A per-package build -- `cargo build --release -p dstack-kms`, the form
the docs prescribe -- now cannot reach it: adding a call to
`kms/src/config.rs` fails with `no method named with_report_data`.
`cargo build --workspace` unifies features and does still compile it in,
so this is a statement of intent with teeth on the release path, not a
hard wall.

Adding the gate immediately found the one legitimate cfg(test) user
outside the simulator, `guest-agent`'s mock platform, which now declares
the feature in `[dev-dependencies]` -- so guest-agent's production build
drops it too.

Also splits out `with_stack_report_data`. The simulator's seeded path
called the full version and then overwrote the quote with a freshly
generated, properly signed one, so the quote-patching half was dead work
that read as if it mattered. It now asks for the half it actually uses.

`tdx_event_log()` reaches `Tdx | GcpTdx`; `tdx_event_log_mut()` reached
only `Tdx`. The two drifted apart because both ended in `_ => None`, so
adding `GcpTdx` to one and not the other compiled fine. The simulator
fills V2 digest preimages through the mut accessor, so on a GCP
attestation it silently filled nothing and returned events without the
preimage `agent_rpc.proto` tells clients to verify against the digest.

Drop the wildcard from all eight accessors on `PlatformEvidence` and
spell the variants out. This is the same failure `with_report_data` had
two commits ago; a wildcard is how a family of per-platform methods
disagrees with itself without anyone noticing.

`tdx_event_log_accessors_agree_on_gcp_tdx` pins the read and mut halves
to the same set and fails against the old match.

Also corrects the comment on the `GcpTdx` arm of `with_report_data`. It
claimed the vTPM quote was left alone because it commits to PCRs rather
than to the report data. That is wrong: its `qualified_data` is
`sha256(tdx_quote)` (attestation.rs:1087), so patching the quote severs
that binding too. The behaviour is right -- re-deriving it would need
the AK to re-sign, and the patch has already invalidated the quote
signature -- but the reason given was not.